feat: add Elysia adapter by wobsoriano · Pull Request #46 · supabase/server

wobsoriano · 2026-05-05T05:17:08Z

What kind of change does this PR introduce?

Feature

What is the current behavior?

@supabase/server ships framework adapters for Hono and H3 / Nuxt, but not for Elysia. Users building APIs with Elysia have to wire up Supabase auth manually with the core primitives.

What is the new behavior?

Adds @supabase/server/adapters/elysia, a first-class plugin adapter for Elysia. Elysia has been gaining significant traction in the TypeScript ecosystem, particularly in the Bun community, for its end-to-end type safety and expressive plugin API.

Usage with a plain Elysia app:

import { Elysia } from 'elysia'
import { withSupabase } from '@supabase/server/adapters/elysia'

const app = new Elysia()
  .use(withSupabase({ auth: 'user' }))
  .get('/games', async ({ supabaseContext }) => {
    const { data: myGames } = await supabaseContext.supabase
      .from('favorite_games')
      .select()

    return myGames
  })

app.listen(3000)

Per-route auth using scoped groups:

const app = new Elysia()
  .get('/health', () => ({ status: 'ok' }))
  .group('/api', (app) =>
    app
      .use(withSupabase({ auth: 'user' }))
      .get('/profile', ({ supabaseContext }) => supabaseContext.userClaims),
  )

Custom error handling via Elysia's onError:

const app = new Elysia()
  .use(withSupabase({ auth: 'user' }))
  .onError(({ code, error, status }) => {
    if (code !== 'SupabaseAuthError') return

    const cause = error.cause as { code?: string; status?: number } | undefined

    return status((cause?.status as 401) ?? 500, {
      error: error.message,
      code: cause?.code,
    })
  })

Additional context

Uses Elysia's .resolve() hook with .as('scoped') so the context propagates to parent app routes.
Auth failures throw a registered SupabaseAuthError, which integrates with Elysia's standard onError flow and preserves the original AuthError on error.cause.Consumers discriminate on code === 'SupabaseAuthError' in onError without needing to import the class.
Test coverage mirrors the Hono and H3 adapter tests.
Docs and package metadata were updated to include Elysia in the adapter tables, exports, and generated API docs.

pkg-pr-new · 2026-05-05T05:18:51Z

Open in StackBlitz

npm i https://pkg.pr.new/@supabase/server@46

commit: 1217b8d

kallebysantos · 2026-05-14T11:56:07Z

+class SupabaseAuthError extends Error {
+  status: number
+  constructor(message: string, status: number, cause: unknown) {
+    super(message, { cause })
+    this.status = status
+  }
+}
+


I'm not really sure why its SupabaseAuthError.
We have EnvError and AuthError classes.

Both sharing similar shape. Maybe better renaming it to SupabaseError instead?

Good call! Renamed to SupabaseError.

The intent behind a wrapper class rather than throwing AuthError directly is to give Elysia consumers a single, stable discriminant in onError regardless of whether the failure was an auth error or an env misconfiguration.

More info https://elysiajs.com/patterns/error-handling

Uhmm so what about registering the original error classes instead of wrapping it?

new Elysia() .error({ EnvError, AuthError, })

Good point! I tried throwing AuthError directly with .error({ AuthError }), but Elysia's error registry inside a scoped plugin doesn't propagate to the parent's onError at runtime, so code === 'AuthError' silently fails even though TS infers it correctly.

We could keep a thin SupabaseError wrapper but expose .code and .status directly on it (no .cause indirection). That way code discrimination still works idiomatically. Open to other suggestions!

So if we pass the AuthError directly, one will check it in the elysia error hook like this:

import { AuthError } from '@supabase/server/errors' app.onError(({ error, status }) => { if (!(error instanceof AuthError)) return return status(error.status as 401, { error: error.message, code: error.code, }) })

but if we create a thin wrapper and expose .code and .status:

app.onError(({ code, error, status }) => { if (code !== 'SupabaseError') return return status(error.status as 401, { error: error.message, code: error.code, }) })

2nd is more idiomatic to Elysia, no extra import, and the code string is the standard discriminant. The first works but bypasses Elysia's custom error system entirely

2nd is more idiomatic to Elysia

Sure! so keep the version you think better aligns to Elysia framework.
Mark it as "resolved" with your confirmation

kallebysantos · 2026-05-14T12:07:36Z

Thanks for contributing,
Just a few questions and adjustments 💚

wobsoriano · 2026-05-14T17:33:38Z

@kallebysantos thanks for the thorough review. Resolved the comments! ❤️

kallebysantos

LGTM!
Please fix the merge conflicts as well give me the confirmation about SupabaseError thing.

Then we should be good to merge!

wobsoriano · 2026-05-16T15:18:40Z

LGTM! Please fix the merge conflicts as well give me the confirmation about SupabaseError thing.

Then we should be good to merge!

Thanks for approving! Going with the thin SupabaseError wrapper as it keeps Elysia's idiomatic code discrimination (code === 'SupabaseError') working while exposing .code and .status directly on the error, so no awkward .cause access 🫡

# Conflicts: # README.md

tomaspozo · 2026-05-18T15:17:50Z

Thanks for approving! Going with the thin SupabaseError wrapper as it keeps Elysia's idiomatic code discrimination (code === 'SupabaseError') working while exposing .code and .status directly on the error, so no awkward .cause access 🫡

Hi @wobsoriano! we are ready to merge this... can you confirm it this is already taken care of fully?

wobsoriano · 2026-05-18T19:07:24Z

Thanks for approving! Going with the thin SupabaseError wrapper as it keeps Elysia's idiomatic code discrimination (code === 'SupabaseError') working while exposing .code and .status directly on the error, so no awkward .cause access 🫡

Hi @wobsoriano! we are ready to merge this... can you confirm it this is already taken care of fully?

I just pushed an update (ref) that gives clean access to .code and .status without a type cast. Also simplified the constructor to take the AuthError directly instead of unpacking its fields.

Tested this locally in a simple Elysia app:

.onError(({ code, error, status }) => {
  if (code !== 'SupabaseError') return
  return status(error.status {
    error: error.message,
    code: error.cause.code,
  })
})

sending a curl request curl -i http://localhost:3000/ -H "Authorization: Bearer sometoken" gives

{"error":"Invalid credentials","code":"INVALID_CREDENTIALS"}

Ready to merge 👍🏼

tomaspozo · 2026-05-19T01:32:22Z

@wobsoriano

One small suggestion before merge: would you consider hoisting code onto the wrapper too, for consistency with status?

Right now .status lives directly on SupabaseError but .code still requires going through .cause...

 class SupabaseError extends Error {
   status: number
   code: string
   declare cause: AuthError
   constructor(inner: AuthError) {
     super(inner.message, { cause: inner })
     this.status = inner.status
     this.code = inner.code
   }
 }

Then the handler becomes uniform:

  .onError(({ code, error, status }) => {
    if (code !== 'SupabaseError') return
    return status(error.status as 401, {
      error: error.message,
      code: error.code,
    })
  })

cause is still there as the typed AuthError for anyone who wants the full object. Happy to merge as-is if you'd rather keep the wrapper minimal.. Flagging since it's a one-liner 😃

wobsoriano · 2026-05-19T15:12:20Z

@tomaspozo

Unfortunately it collides with an Elysia internal: when a thrown error has an own .code property, Elysia uses its value as the code in onError instead of the .error() registry key. So with this.code = inner.code, the handler sees code === 'INVALID_CREDENTIALS' instead of code === 'SupabaseError', and the discrimination check never passes.

That's also why .status is safe to hoist but .code isn't. Elysia doesn't treat .status specially. Keeping .code off the wrapper and behind .cause.code is the workaround.

So if you have this in onError:

.onError(({ code, error }) => {
  console.log('code value:', code)
  console.log('code === SupabaseError:', code === 'SupabaseError')
  
  if (code !== 'SupabaseError') return
  
  // ...
 })

The output is:

  code value: INVALID_CREDENTIALS
  code === SupabaseError: false

tomaspozo · 2026-05-19T15:16:46Z

Got it! Thanks for the explanation. Going to merge this now, and create a new release!

Resolves conflicts with the Elysia adapter (supabase#46) and the 1.1.0 release that landed on main while review feedback was being addressed. - README.md / src/adapters/README.md: list both Elysia and NestJS in the adapter tables; preserve the community-driven note added upstream. - package.json / jsr.json / tsdown.config.ts: combine Elysia + NestJS entries, peer deps, and bundle externals. Keep upstream's `@supabase/supabase-js` ^2.105.4 bump. - pnpm-workspace.yaml: set `allowBuilds` policy for `@nestjs/core` and `@swc/core` to `false` — they're dev-only deps with no native bindings we need to compile. - pnpm-lock.yaml: regenerated.

wobsoriano marked this pull request as ready for review May 5, 2026 17:49

wobsoriano requested review from a team as code owners May 12, 2026 23:13

wobsoriano force-pushed the rob/elysia-adapter branch from 396ca1a to 2633af3 Compare May 12, 2026 23:14

kallebysantos requested changes May 14, 2026

View reviewed changes

kallebysantos approved these changes May 16, 2026

View reviewed changes

wobsoriano added 7 commits May 16, 2026 08:15

feat: add Elysia adapter

8cff262

chore: remove added property in package.json

2e4f910

chore: dedupe

d0d7b0a

chore: match existing files markdown file location

8f68ba9

chore: match v1 API

49f183b

chore: resolve review

584153d

chore: dedupe

1217b8d

wobsoriano force-pushed the rob/elysia-adapter branch from b3a3438 to 1217b8d Compare May 16, 2026 15:17

Merge remote-tracking branch 'origin/main' into rob/elysia-adapter

260c740

# Conflicts: # README.md

chore: type SupabaseError.cause and simplify constructor

58b2cb4

tomaspozo merged commit 148169e into supabase:main May 19, 2026

supabase-releaser Bot mentioned this pull request May 18, 2026

chore(main): release server 1.1.0 #58

Merged

Uh oh!

Conversation

wobsoriano commented May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What kind of change does this PR introduce?

What is the current behavior?

What is the new behavior?

Additional context

Uh oh!

pkg-pr-new Bot commented May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kallebysantos May 14, 2026

Choose a reason for hiding this comment

Uh oh!

wobsoriano May 14, 2026

Choose a reason for hiding this comment

Uh oh!

kallebysantos May 14, 2026

Choose a reason for hiding this comment

Uh oh!

wobsoriano May 14, 2026

Choose a reason for hiding this comment

Uh oh!

wobsoriano May 14, 2026

Choose a reason for hiding this comment

Uh oh!

kallebysantos May 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kallebysantos commented May 14, 2026

Uh oh!

wobsoriano commented May 14, 2026

Uh oh!

kallebysantos left a comment

Choose a reason for hiding this comment

Uh oh!

wobsoriano commented May 16, 2026

Uh oh!

tomaspozo commented May 18, 2026

Uh oh!

wobsoriano commented May 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tomaspozo commented May 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wobsoriano commented May 19, 2026

Uh oh!

tomaspozo commented May 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

wobsoriano commented May 5, 2026 •

edited

Loading

pkg-pr-new Bot commented May 5, 2026 •

edited

Loading

kallebysantos May 16, 2026 •

edited

Loading

wobsoriano commented May 18, 2026 •

edited

Loading

tomaspozo commented May 19, 2026 •

edited

Loading